This invention relates to a framework for representation and manipulation of record oriented data. Particularly, a preferred embodiment of the framework is designed in and for the Java language, has a concrete class implementation written in Java capable of handling C language data types and provides the ability to access stored or sent records, created by an application written in the C language, from applications written in the Java language.
The Java(trademark) language has quickly become one of the accepted languages for writing enterprise-level applications. For many companies and other organizations it has in fact become the language of choice for new software applications. This is not only true for web-based software applications running in a browser (such as applets), but exceedingly more so for traditional full-function software applications that include user interface, as well as distribution and server-side resource access.
Nevertheless, the bulk of enterprise data continues to reside either in the traditional database or some record-oriented store (e.g. VSAM on S/390(copyright)). This enterprise data is processed by existing line-of-business software applications, the majority of which are written in traditional programming languages such as COBOL and C. While the Java language does provide support for database access (e.g. Java Database Connectivity (JDBC) function), it currently has no effective facility for handling non-database record data.
It is therefore desirable to provide for a framework for representation and manipulation of record oriented data, preferably a framework designed in and for the Java language. As used herein, a record is loosely defined as a logical collection of application data elements or fields, related by some application-level semantic, that is stored and retrieved (or sent and received) in a computer system as a unit (e.g. a contiguous area of bytes). For example, referring to FIG. 1, an Invoice record may be defined by a software application to have the form as shown and stored on a computer usable medium such as a hard drive disk. Particularly, the invoice record of FIG. 1 includes data elements in a contiguous group of bytes (0 to 90) semantically allocated wherein bytes 0 to 10 are allocated to the data element Invoice Number 10 containing data of the integer data type, bytes 11 to 30 are allocated to data element Purchaser Name 20 containing data of the character data type, bytes 31 to 80 are allocated to data element Purchaser Address 30 containing data of the character data type, and bytes 81 to 90 are allocated to data element Amount 40 containing data of the floating point data type. Typically, the record is defined by means of a data structure in an application written in a traditional programming language such as COBOL and the individual data elements can be directly accessed through that application or another application written in the same programming language. Accordingly, the framework of the present invention provides access from applications written in another programming language, preferably the Java language, to such records by describing and correctly converting record data in such records.
The present invention builds upon a similar framework provided as part of the IBM(copyright) VisualAge(copyright) for Smalltalk product. Some of the similarities between this Smalltalk framework and the framework of the present invention include provision for converting between record bytes and the framework representation of the data only when the corresponding field is accessed (a xe2x80x9clazy fetchxe2x80x9d mechanism). Both frameworks also make a distinction between dynamic and custom records, although in the Smalltalk framework, the concept is not apparent to the user, nor does the user have a choice of between using dynamic or custom records. Further, both frameworks provide for the iteration over the fields of a dynamic record.
Nevertheless, the Java framework of the present invention provides a number of improvements and/or distinctions over the Smalltalk framework. The framework of the present invention has an advantage of providing variable length record support, as well as the ability to mix fixed length and variable length records together in one record. The present invention has a further advantage of providing support for overlaid fields. Additionally, the invention advantageously provides distinct typesets which are used by generic fields. In the Smalltalk framework, the field and type were combined together and so instead the distinct typesets of the present invention allow a new typeset to be easily incorporated into the framework for use. Also, the invention advantageously provides for xe2x80x9cpackingxe2x80x9d a record after creating the fields which allows for the dynamic record to be fully editable i.e. a user can add, delete, rename, and/or replace fields of a record. Furthermore, the builder tool support classes of the present invention beneficially allow for graphical user interface (GUI) based editors to manipulate the records.
In sum, it is desirable to provide a method, system and article of manufacture comprising a computer usable medium having computer readable program code means therein for access from applications written in a computer programming language, preferably the Java language, to records created by an application written in another programming language by describing and correctly converting record data in such records.
Accordingly, the present invention provides new and useful methods, systems and articles of manufacture comprising a computer usable medium having computer readable program code means therein are directed to a framework for representation and manipulation of record oriented data. Particularly, the framework of the present invention provides access from applications written in a computer programming language, preferably the Java language, to records created by an application written in another programming language by describing and correctly converting record data in such records.
The present invention provides a computer-implemented method for accessing a record, said record having a field and record bytes, comprising the steps of (a) modeling the record by means of an implementation of a framework, wherein the framework comprises a record interface, a record type interface, a field interface and a type interface, and (b) accessing the record bytes through said implementation of the framework. The above-method is further provided with a record interface that associates a record type with the record bytes and describes attributes of the record bytes in terms of data encoding characteristics. Additionally, the record interface may comprise a dynamic record interface, said dynamic record interface providing an accessor to the field in accordance with an identifier of the field. The record interface may also comprise a custom record interface, said custom record interface providing a user-defined accessor to the record bytes. The user may also selectively choose implementation of the dynamic record interface or the custom record interface.
The above-method may also have a record type interface that collects a field descriptor of the field in the record. The record type interface may further comprise a dynamic record type interface, said dynamic record type interface providing the ability to add, insert, delete, or retrieve field descriptors. The dynamic record type interface may also provide the ability to iterate over field descriptors of the record through an enumerator. Additionally, the record type interface may provide the capability to define new records of the record type.
The above-method may also have a field interface that associates a field descriptor with the field of the record, said field descriptor comprising a field name, a data type, and a field relative offset into the record bytes. The field interface can provide an accessor to the field in accordance with an absolute offset with respect to the record in terms of record bytes. Further, the field interface may comprise a nested record field interface, said nested record interface defining a structure of records within the record. The field interface may also comprise an overlay field interface, said overlay field interface defining a union of fields anchored to a same offset within the record bytes.
The above-method may be provided with a type interface that defines a data type of the field. The data type may be configurable and supplied by the user. Further, the type interface may comprise a static conversion method and an accessor to the record bytes of the field. The type interface may also comprise a fixed length type interface, said fixed length type interface providing an accessor to the record bytes in accordance with a fixed offset of the field. The type interface may also comprise a variable length type interface, said variable length type interface providing an accessor to (a) read the record bytes of the record and unpack the record bytes into segments corresponding to the fields of the record; (b) store said segments in a field level cache for access; and (c) pack the segments back into a contiguous array of record bytes of the record and write the contiguous array of record bytes of the record. Providing an accessor to unpack the record bytes may further comprise providing a method that returns record data of the field without the record data that delimits the field in the record and providing an accessor to pack the record bytes may comprise providing a method that attaches delimiting record data to the record data of a field according to the data type of the field.
The above-method is also provided such that the step of accessing the record bytes comprises converting the record bytes of a field into a framework representation only when said field in the record is accessed. Further, the above-method is provided such the interfaces may be extended by a user to define additional interfaces.
The above-method may be implemented by means of an object-oriented computer programming language, particularly Java, C++ or SmallTalk. Also, the record in the above-method may have specific computer programming language record data characteristics, particularly characteristics attributable to COBOL, C or PL1. The record in the above-method may also have a record identifier, said record identifier comprising the record bytes and record attributes of the record.
The above-method is also provided such that the step of accessing the record bytes comprises optionally providing access to the record data in hierarchical form or flat form Providing access to the record data in hierarchical form may comprise generating classes according to a hierarchical field structure of the record, each class comprising an accessor for the fields in the structure. Providing access to the record data in flat form may comprise generating a single class for a field structure of the record, said class comprising an accessor for the fields in the structure. Providing access to the record data, the record containing an array of subrecords, may comprise generating a class for a subrecord, said class comprising an accessor for the fields of the subrecord.
There is also provided an article of manufacture comprising a computer usable medium having computer readable program code means therein for performing the above-method and its variations.
The present invention also provides a computer system for accessing a record, said record having a field and record bytes, comprising the record stored on a data storage device connected to a computer; and the computer comprising code means, executed by the computer, for retrieving record data from the record, code means for modeling the record by means of an implementation of a framework, wherein the framework comprises a record interface, a record type interface, a field interface and a type interface, and code means for accessing record data of the record through said implementation of the framework. The above-system is also provided with a record interface associates a record type with the record bytes. The record interface may further describe attributes of the record bytes in terms of data encoding characteristics. The record interface may also comprise a dynamic record interface, said dynamic record interface providing an accessor to the field in accordance with an identifier of the field. The record interface may also further comprise a custom record interface, said custom record interface providing a user-defined accessor to the record bytes. The user may also selectively choose implementation of the dynamic record interface or the custom record interface.
The above-system may also have a record type interface that collects a field descriptor of the field in the record. The record type interface may further comprise a dynamic record type interface, said dynamic record type interface providing the ability to add, insert, delete, or retrieve field descriptors. The dynamic record type interface may also provide the ability to iterate over field descriptors of the record through an enumerator. Additionally, the record type interface may provide the capability to define new records of the record type.
The above-system may also have a field interface that associates a field descriptor with the field of the record, said field descriptor comprising a field name, a data type, and a field relative offset into the record bytes. The field interface can provide an accessor to the field in accordance with an absolute offset with respect to the record in terms of record bytes. Further, the field interface may comprise a nested record field interface, said nested record interface defining a structure of records within the record. The field interface may also comprise an overlay field interface, said overlay field interface defining a union of fields anchored to a same offset within the record bytes.
The above-system may be provided with a type interface that defines a data type of the field. The code means for the data type may be configurable and supplied by the user. Further, the type interface may comprise a static conversion method and an accessor to the record bytes of the field. The type interface may also comprise a fixed length type interface, said fixed length type interface providing an accessor to the record bytes in accordance with a fixed offset of the field. The type interface may also comprise a variable length type interface, said variable length type interface providing an accessor to (a) read the record bytes of the record and unpack the record bytes into segments corresponding to the fields of the record; (b) store said segments in a field level cache for access; and (c) pack the segments back into a contiguous array of record bytes of the record and write the contiguous array of record bytes of the record. Providing an accessor to unpack the record bytes may further comprise providing a method that returns record data of the field without the record data that delimits the field in the record and providing an accessor to pack the record bytes may comprise providing a method that attaches delimiting record data to the record data of a field according to the data type of the field.
The above-system is also provided such that the code means for accessing the record bytes comprises converting the record bytes of a field into a framework representation only when said field in the record is accessed. Further, the above-system is provided such the interfaces may be extended by a user to define additional interfaces.
The above-system may be implemented by means of an object-oriented computer programming language, particularly Java, C++ or SmallTalk. Also, the record in the above-system may have specific computer programming language record data characteristics, particularly characteristics attributable to COBOL, C or PL1. The record in the above-system may also have a record identifier, said record identifier comprising the record bytes and record attributes of the record.
The above-system is also provided such that the code means for accessing the record bytes comprises optionally providing access to the record data in hierarchical form or flat form. The code means for providing access to the record data in hierarchical form may comprise generating classes according to a hierarchical field structure of the record, each class comprising an accessor for the fields in the structure. The code means for providing access to the record data in fiat form may comprise generating a single class for a field structure of the record, said class comprising an accessor for the fields in the structure. The code means for providing access to the record data, the record containing an array of subrecords, may comprise generating a class for a subrecord, said class comprising an accessor for the fields of the subrecord.
The present invention also provides an object-oriented framework for use in a computer system that supports an object-oriented programming environment, wherein the framework provides access to a record in said computer system said record having a field and record bytes, and includes: a record class, said record class associating a record type with the record bytes; a record type class, said record type class collecting a field descriptor of the field in the record; a field class, said field class associating the field descriptor with the field of the record, said field descriptor comprising a field identifier, a data type, and a field relative offset into the record bytes; and a type class, said type class defining the data type of the field. The above-framework may provide that the record class further describes attributes of the record bytes in terms of data encoding characteristics. The record class may also comprise a dynamic record class, said dynamic record class providing an accessor to the field in accordance with an identifier of the field. The record class may also comprise a custom record class, said custom record class providing a user-defined accessor to the record bytes. The user may also selectively choose implementation of the dynamic record class or the custom record class.
The above-framework may also be provided such that the record type class comprises a dynamic record type class, said dynamic record type class providing the ability to add, insert, delete, or retrieve field descriptors. The dynamic record type class may also provide the ability to iterate over field descriptors of the record through an enumerator. The record type class may also provide the capability to define new records of the record type.
The above-framework may also have the field class provide an accessor to the field in accordance with an absolute offset with respect to the record in terms of record bytes. Further, the field class may comprise a nested record field class, said nested record class defining a structure of records within the record. The field class can also comprise an overlay field class, said overlay field class defining a union of fields anchored to a same offset within the record bytes.
The above-framework may also be provided such that the data type may be configurable and supplied by the user. Further, the type class may comprise a static conversion method and an accessor to the record bytes of the field. The type class may also comprise a fixed length type class, said fixed length type class providing an accessor to the record bytes in accordance with a fixed offset of the field. The type class may also comprise a variable length type class, said variable length type class providing an accessor to: (a) read the record bytes of the record and unpack the record bytes into segments corresponding to the fields of the record; (b) store said segments in a field level cache for access; and (c) pack the segments back into a contiguous array of record bytes of the record and write the contiguous array of record bytes of the record. Providing an accessor to unpack the record bytes further may comprise providing a method that returns record data of the field without the record data that delimits the field in the record and providing an accessor to pack the record bytes further comprises providing a method that attaches delimiting record data to the record data of a field according to the data type of the field.
The above-framework may be provided such that the classes may be extended by a user to define additional classes. Further, the classes may be implemented by means of an object-oriented computer programming language, particularly Java, C++ or SmallTalk. Also, the record in the above-framework may have specific computer programming language record data characteristics, particularly characteristics attributable to COBOL, C or PL1. The record in the above-framework may also have a record identifier, said record identifier comprising the record bytes and record attributes of the record.
The present invention also provides a method of operating a computer system that provides an object-oriented programming environment, having one or more records, and communicating with one or more users executing object-oriented application programs for access to the record, the method comprising the steps of: (a) modeling the record in accordance with an object-oriented framework comprising: (i) a record class, said record class associating a record type with the record bytes; (ii) a record type class, said record type class collecting a field descriptor of the field in the record; (iii) a field class, said field class associating the field descriptor with the field of the record, said field descriptor comprising a field identifier, a data type, and a field relative offset into the record bytes; and (iv) a type class, said type class defining the data type of the field; and (b) accessing the record bytes through said framework. The above-method may be implemented by means of an object-oriented computer programming language, particularly Java, C++ or SmallTalk. Also, the record class may comprise a dynamic record class, said dynamic record class providing an accessor to the field in accordance with an identifier of the field. The record class may also comprise a custom record class, said custom record class providing a user-defined accessor to the record bytes. The user may also selectively choose implementation of the dynamic record class or the custom record class.
The above-method may also be provided such that the data type may be configurable and supplied by the user. Further, the type class may comprise a fixed length type class, said fixed length type class providing an accessor to the record bytes in accordance with a fixed offset of the field. Also, the type class may also comprise a variable length type class, said variable length type class providing an accessor to: (a) read the record bytes of the record and unpack the record bytes into segments corresponding to the fields of the record; (b) store said segments in a field level cache for access; and (c) pack the segments back into a contiguous array of record bytes of the record and write the contiguous array of record bytes of the record.
The framework of the present invention addresses flexibility and speed of access. Record access requires the ability to define the data element content of each record. This requires a flexible descriptor structure capable of expressing the record construction semantics used by the various target environments containing the record. Further, a user needs the ability to create such record descriptors on-the-fly or dynamically as part of an application, as well as the ability to predefine these as separate classes. In addition, in the case of existing applications, the record formats are well known ahead of tire, and do not frequently change (if at all). Consequently, it is desirable to be able to provide optimized run-time accessors (a combination of read/write methods or in Java, get/set methods) that bypass the overhead of lookup structures as an alternative to dynamic descriptors.
Since in general, records can have fixed or variable length, the framework of the present invention advantageously is able to manipulate records which are fixed or variable length in nature, or a mixture of the two.
Furthermore, most of today""s record data has been written by applications written in traditional computer programming languages such as COBOL instead of applications written in modern computer programming languages such as Java and C++. Consequently, record access from such modern languages such as Java must be able to handle data conversions required by cross-language access. In addition, many of the users of the record support may provide cross-system access e.g. remote record file input/output which also requires conversion of record data.
Most existing record-oriented applications have not been designed with modem programming language application, such as Java applications, in mind. As a result, it is quite likely that only a small portion of a retrieved record may end up being used by a modem language application. Since unnecessary data conversions of large structures are expensive, the framework advantageously should delay any data conversions until requiredxe2x80x94the xe2x80x9clazy fetchxe2x80x9d mechanism as described above.
The framework of the present invention also has an advantage of allowing the user to target different environments. By providing different data type converters and allowing new data type converters to be added, a user can access record data on different environments.
The framework also advantageously provides, in a preferred embodiment, direct support of Java types. Accessors that manipulate base Java language types should return/take as argument the base type, rather than its object counterpart (e.g. int, rather than Integer). This objective is partly driven by programmer-user convenience, and partly by performance.
Although the primary intent of the framework is to supply a runtime implementation of record-oriented data handling, a set of builder-type tools could be provided in order to assist in construction of record oriented structures. The framework therefore needs to be able to provide design-time information in dealing with its base constructs within a builder tool
Lastly, it is an advantage of the present invention to provide usability gains and convenience to a user by allowing access to record field data by name. Any data conversion required on the data is handled when a user invokes the appropriate accessors. The user does not need to understand the format of the data, only the name of field in the record that is of interest. It is a further advantage of the present invention to provide usability and performance gains by providing for selective generation of code, representing a record, in flat or hierarchical form.